Method for managing two-way alternate communication in semi-duplex mode through a packet switching transport network

ABSTRACT

The invention concerns a method for managing two-way alternate communication in semi-duplex mode between at least two terminal facilities ( 201 - 203 ) of a packet switching transport network in non-connected mode ( 300 ), wherein an indicating element (M) serves, when it is present with a first specific value in the packets transmitted from one ( 201 ) of said terminal facilities ( 201 - 203 ) to a central facility ( 400 ) managing the communication, to indicate to said central facility ( 400 ) that said terminal facility ( 201 ) acknowledges receipt of the right to transmit which is granted to it by said central facility ( 400 ) and that it requests continuation of said right to transmit.

[0001] The present invention relates to a method for managing a groupcommunication in half-duplex mode between various end equipments of apacket switching network.

[0002] It concerns the field of packet switching transport networks innon connected mode, in particular IP (Internet Protocol) networks.

[0003] It finds applications, in particular in radiocommunicationssystems, especially private systems for professionalradiocommunications, such as those intended for the police or firedepartments.

[0004] These systems have a particular mode of communication, theso-called half-duplex mode, which has long since disappeared from publicsystems (public switched telephone network, or publicradiocommunications systems such as GSM). In the half-duplex mode, amobile station can send or receive, but cannot perform both theseoperations at once (i.e., push-to-talk functions or emit/receivefunction). Moreover, a single mobile station must be authorized to sendat a given instant, the data flow sent by this mobile station beingretransmitted to the mobile station or stations participating in thecommunication (also called a call), that is to the mobile stationconcerned when dealing with an individual communication or to all themobile stations participating in the communication when dealing with agroup communication.

[0005] A particular network equipment, called the central equipment inwhat follows, performs arbitration in case of conflict between requestsfor the right to send reaching it from different mobile stations throughcorresponding base stations. This arbitration is based on a level ofpriority and/or on the identity of the mobile stations. The centralequipment notifies the various mobile stations of the result of thisarbitration, that is it indicates the mobile station to which the rightto send has been granted. It must also, as the case may be, warn theother mobile stations of the end of the alternation (i.e., press-to-talktime period, or emit/receive time period) in progress, that is of thecessation of sending by the mobile station which had previously obtainedthe right to send, so that these other mobile stations can in their turnrequest the right to send. It must also, as the case may be, allow thepreemption of alternation by a mobile station having a higher prioritythan that which enjoys the right to send for the alternation inprogress.

[0006] The major development of packet switching transport networks innon connected mode makes it possible to envisage the management of acommunication between at least two base stations of aradiocommunications system that are regarded as end equipments of such anetwork.

[0007] In particular, use may be made of the mechanisms of themultimedia conferences defined within the framework of internetprotocols, that is protocols for networks operating according to the IPprotocol (J. Postel, “Internet Protocol”, RFC 791, IETF, September 1981)which has been standardized by the IETF (“Internet Engineering TaskForce”) organization in the above RFC (Request For Comments). Thesemultimedia conferences are based on the implementation of a multimediavideo conferencing equipment or MCU (standing for “MultimediaConferencing Unit”), and offer an advantageous support for producingnumerous types of telephony and videophony services for example.However, the principal internet protocols have been designed forconventional multimedia applications and do not take account of thespecific features of certain applications of professionalradiocommunications networks, and in particular the management ofalternation for communications in half-duplex mode.

[0008] The object of this invention is to propose an adaptation of theprotocols implemented in packet switching transport networks in nonconnected mode, allowing the management of alternation forcommunications in half-duplex mode, be they individual communications orgroup communications.

[0009] This aim is attained by virtue of a method for managing two-wayalternate communication in half-duplex mode between at least two endequipments of a packet switching transport network in non connectedmode, wherein an indication element has as function, when it is presentwith a first given value in packets transmitted from one of said endequipments to a central equipment undertaking the management of thecommunication, to indicate to said central equipment, on the one hand,that said end equipment acknowledges receipt of the right to send thatis granted to it by said central equipment and, on the other hand, thatit is requesting the maintaining of this right to send.

[0010] This indication element may moreover have as function, when it ispresent with a second given value in packets transmitted by the centralequipment to the end equipments, to indicate to said end equipments thatthey may request the right to send.

[0011] When the packet switching transport network in non connected modeis an IP network, the central equipment may be an MCU, and the framestransmitted over the network may be RTP packets (standing for “Real timeTransport Protocol”, see H. Schulzrinne, “RTP: a Transport Protocol forReal-Time Applications”, RFC 1889, IETF, January 1996), thecommunication then being set up as an RTP/RTCP session (standing for“Real Time Transport Control Protocol”).

[0012] According to an advantageous characteristic of the invention, theindication element may then be the marking bit M of the header of theRTP packets, said first value of the indication element being the logicvalue 1 or 0, and said second value of the indication element being thelogic value 0 or 1, respectively.

[0013] The invention also proposes the application of the methodhereinabove to a radiocommunications system, in particular a privatesystem for professional radiocommunications. The method then allows themanagement of alternation for individual communications or groupcommunications between mobile stations when at least certain of the endequipments of the packet switching transport network are also basestations of said radiocommunications system.

[0014] The invention also proposes a radiocommunications system, inparticular a private system for professional radiocommunications,comprising base stations and a network equipment that are linked by apacket switching transport network in non connected mode, wherein saidbase stations comprise means for the implementation of the method asnetwork end equipment and wherein said network equipment comprises meansfor the implementation of the method as central equipment.

[0015] The invention further proposes a base station intended for use asend equipment in a system as defined hereinabove.

[0016] The invention finally proposes a multimedia videoconferencingequipment intended to be used as central equipment in a system asdefined hereinabove.

[0017] Other characteristics and advantages of the invention will becomefurther apparent on reading the following description. The latter ispurely illustrative and should be read in conjunction with the appendeddrawings wherein are represented:

[0018]FIG. 1 is the diagram of a radiocommunications system according tothe invention;

[0019]FIG. 2 is a chart presenting a set up protocol for establishing anindividual communication involving two base stations of a systemaccording to FIG. 1;

[0020]FIG. 3 is a diagram illustrating the topology of an RTP/RTCPsession in the case of an individual communication;

[0021]FIG. 4 is a chart presenting a set up protocol for establishing agroup communication involving three base stations of a system accordingto FIG. 1;

[0022]FIG. 5 is a diagram illustrating the topology of an RTP/RTCPsession in the case of the group communication;

[0023]FIG. 6 is a chart illustrating the format of the header of an RTPpacket;

[0024]FIG. 7 is a chart illustrating the format of the payload of an RTPpacket;

[0025]FIG. 8 is a flowchart illustrating steps of the method ofoperation of a base station comprising means for the implementation ofthe method according to the invention as end equipment;

[0026]FIG. 9 is a flowchart illustrating steps of the operation of amultimedia video conferencing equipment (MCU) for the implementation ofa method according to the invention as central equipment; and

[0027]FIG. 10 is a diagram illustrating the topology of an RTP/RTCPsession in the case of a group communication involving several levels ofMCU.

[0028] Represented diagrammatically in FIG. 1 is a radiocommunicationssystem according to the invention.

[0029] In the example represented, mobile stations 101, 102 and 103 arein the zone of coverage of base stations 201, 202 and 203 respectively.It is recalled that the base stations are fixed equipments of the radiosubsystem of the radiocommunications system, which undertake the radiointerface with the mobile stations.

[0030] The base stations are attached to a packet switching transportnetwork in non connected mode 300, such as an IP network. Statedotherwise, the base stations 201, 202 and 203 are also end equipments ofan IP network. Packet switching is effected by routers 301, 302 and 303.

[0031] A network equipment 400 is attached to the network 300. It ispreferably an MCU, the customary function of which consists in groupingtogether or in switching several real time data streams (for example, adata stream for voice and/or a data stream for video) so as to constructa stream distributed to several receivers, producing a multimediaconferencing configuration.

[0032] A call server 500 is also attached to the network 300. Thisequipment analyzes calls and sets up multimedia communications on thenetwork 300. It cooperates with a location database 600, which is alsoattached to the network 300, and which contains information indicating,among other things, the cell under whose coverage the mobile stationcalled is situated, thus allowing correct routing of the calls.

[0033] Equipments other than those represented in FIG. 1 may naturallyform part of the radiocommunication system. These equipments notparticipating in the mechanisms of the method according to theinvention, it is unnecessary to describe them here. Furthermore, thevarious equipments (base stations, MCU, call server, etc.), althoughrepresented here in the form of distinct physical entities for clarityof the account, may be duplicated, joined or dispersed in various wayswithout departing from the framework of the invention.

[0034] The chart of FIG. 2 presents a procedure for setting up anindividual communication between the mobile station 101 and the mobilestation 102 (here on the initiative of the mobile station 101), whichuses an application layer signaling protocol such as the SIP protocol(M. Handley et al., “SIP: Session Initiation Protocol”, RFC 2543, IETF,March 1999).

[0035] The SIP addresses are similar to electronic messaging addresses,that is they are of the form “user@host”, where the “user” fielddesignates for example a user name or a telephone number, and where the“host” field designates for example a domain name or an address innumerical form. The SIP protocol provides for schemes, in particularschemes called INVITE and ACK, used to initialize a call session betweentwo SIP users. The responses to the messages sent within the frameworkof these schemes are defined by classes of codes.

[0036] Thus, on request from the mobile station 101, the base station201 generates an invitation message INVITE addressed to the call server500. This INVITE message mentions as destination the mobile station 102,whose SIP address is for example “mob102@home”, where “mob102” is theuser name of the mobile station 102 and where “home” is the address of anominal location register called the HLR (standing for “Home LocationRegister”) which accommodates the location database 600.

[0037] In the example represented, the call server 500 responds, afterconsulting the location database 600, with a message indicating a code“302” which signifies that the mobile station is momentarily under thecoverage of another base station (the code 302 signifies “Movedtemporarely”). This message indicates moreover in a “Contact” field theaddress of the MCU processing the communication (here the MCU designatedby the address “MCU 400”) and, in an “Also” field, the SIP address ofthe mobile station 102 under the coverage of the base station 202 (whoseaddress is “st202” in the example).

[0038] The base station 101, in accordance with the SIP protocol,repeats its INVITE message, this time addressing it to the MCU. 400, andmoreover mentioning in the “Also” field the address “mob102@st202” ofthe mobile station 102 under the coverage of the base station 202.

[0039] The MCU 400 then sends an INVITE message destined for the basestation 202, mentioning as party to the call the mobile station 102designated by its address “mob102@st202”.

[0040] When the mobile station 102 has gone off-hook, the base station202 sends as a response to the MCU a validation message (code “200 OK”)which is acknowledged by the MCU 400 with the aid of an acknowledgemessage ACK.

[0041] The MCU 400 then sends the base station 201 a validation message“200 OK”, which is acknowledged by an acknowledge message ACK. Thecommunication is then set up, for example in the form of an RTP/RTCPsession, and conversation can then commence.

[0042]FIG. 3 gives the topology of the RTP/RTCP session for theindividual communication initialized according to the proceduredescribed hereinabove with regard to FIG. 2. The RTP packets 10 receivedby the MCU 400 of the base station 201 are retransmitted to the basestations 201 and 202, after possible processing, in the form of RTPpackets 11 and 12. Moreover, RTCP packets (not represented) aretransmitted in response to the transmission of the RTP packets so as toensure the control of the transport service.

[0043] The setting up of a group communication between more than twomobile stations may naturally be based on an adaptation of the SIPprotocol. The initialization of a group communication between the mobilestations 101, 102 and 103 which are under the coverage of the basestations 201, 202 and 203 respectively, is illustrated by the chart ofFIG. 4. The RTP/RTCP session is here set up on the initiative of themobile station 101.

[0044] In such a case, several “Also” fields, followed by the respectiveSIP addresses of all the mobile stations party to the groupcommunication processed by the MCU 400 (here the addresses“mob102@st202” and “mob103@st203” of the mobile stations 102 and 103respectively, are included in the INVITE messages transmitted by thebase station 201 to the call server 500 or to the MCU 400. The MCU 400then transmits an INVITE message destined for each of the other basestations 202 and 203 which are party to the group communication.

[0045] In this case, moreover, each of the INVITE messages comprisesadditionally, in the body of the message, a description of the RTP/RTCPsession in accordance with the SDP protocol (M. Handley et al., “SDP:Session Description Protocol”, RFC 2327, IETF, April 1998). Thisdescription is for example denoted “Ses1” in the chart of FIG. 4. Theuse of this description allows the exchange of information between theequipments participating in the group communication, on the choice ofthe UDP ports, that is of the ports of the equipments used by the UDPprotocol (J. Postel, “User Datagram Protocol”, RFC 768, IETF, August1980), which have to be used for the setting up of the RTP/RTCPsessions, as well as on the nature of the profile of the data exchangedin the course of the session (audio or video, type of coding, samplingfrequency, etc). It will be noted that, in the “Also” field of theresponse message transmitted by the call server 500 to the base station201 that dispatched the first INVITE message, the call server 500 canalso propose an identifier of the mobile stations corresponding, forexample, to a temporary number acquired during registration.

[0046] Represented in FIG. 5 is the topology of the RTP/RTCP session forthe group communication initialized according to the procedure describedhereinabove with regard to the chart of FIG. 4. The RTP packets 10received by the MCU 400 of the base station 201 are retransmitted tobase stations 201, 202 and 203, after possible processing, in the formof RTP packets 11, 12 and 13 respectively. For the sake of clarity, theRTCP packets which are transmitted in response to the transmission ofthe RTP packets, are not represented.

[0047] The conventional audio profiles defined in RFC 1889 mentionedabove do not make it possible to process certain particular operationsof private systems for professional radiocommunications, such as themanagement of alternation in half-duplex mode communications. This iswhy the invention proposes an adaptation of RTP allowing management ofalternation in an individual or group communication in half-duplex mode.

[0048] As is represented in the diagrams of FIG. 3 and FIG. 5, the RTPpackets comprise a header HD, and a body of data PL containing thepayload, that is the audio or video data proper.

[0049] The chart of FIG. 6 represents the format of the header of apacket according to the RTP protocol (see RFC 1889, mentioned above).This header comprises the following fields:

[0050] a V (“Version”) field, whose length is equal to two bits, whichcontains a version number of the protocol (V=2 in the case represented);

[0051] a P (“Padding”) bit, which indicates, when it has the logic value1, the presence of complementary bytes at the end of the RTP packet.These complementary bytes make it possible to obtain a length exhibitingcertain characteristics, for example for cryptography purposes;

[0052] an X (“Extension”) bit which indicates when it has the logicvalue 1, the presence of an extension header;

[0053] a CC (“CSRC Count”) field, with a length equal to four bits, thevalue of which defines the number of identifiers of CSRC type(“Contributing Source Identifiers”, see later) following the fixedheader.

[0054] an M (“Marker”) bit, which is a marking bit defined by theprofile, that is that can be used as a function of the requirements ofthe application;

[0055] a PT (“Payload Type”) field, with a length equal to seven bits,which identifies the type of the payload (audio or video). This fieldcontains a value which is either a number registered with the IANA(“Internet Assigned Numbers Authority”), or a number chosen dynamicallyfrom a list of usable values and whose significance can be chosen by theequipments that are party to the communication.

[0056] a sequence number, the length of which is equal to 16 bits, whichis initialized with a random value at the start of sending of an RTPpacket stream by an end equipment, and which is incremented by one unitfor each packet dispatched. This number allows the other end equipmentor other end equipments of the RTP session to reorder the packets or todetect the missing packets in case of loss of RTP packets during theirtransport through the IP network;

[0057] a timestamp, the length of which is equal to 32 bits, and whichdates the instant of generation of the payload of each of the packets.This stamp thus allows the end equipments to calculate the fluctuationsin the transport time through the network and thus, to plan the buffermemories necessary for guaranteeing optimal service quality. Thetimestamp is obtained from a clock whose resolution is sufficient toallow synchronization and calculation of jitter. The initial value ofthe timestamp is determined randomly, as for the sequence number;

[0058] an SSRC synchronization source identifier, the length of which isequal to 32 bits, and which designates the source of the synchronizationof the RTP packets. This source may be the end equipment which generatesthe RTP packet, but it may also be an intermediate device of the networkcalled a mixing entity (or mixer), which creates a new stream of RTPpackets from RTP packets received from the sources proper, after havingmodified the synchronization thereof. In the latter case, the SSRCidentifier designates the mixing entity;

[0059] a variable length field, containing a list of CSRC contributingsource identifiers, each coded on 32 bits, the number thereof beingindicated in the CC field mentioned above (there may be between 0 and 15such codes in the list). These contributing sources are the endequipments that generate the payload of the RTP packet. The CSRC codesare inserted by the mixing equipments, on the basis of the SSRC codes ofthe contributing sources.

[0060] The first twelve bytes are present in all the RTP packets, whilethe list of CSRC identifiers is present only if it is inserted by one ormore mixing entities.

[0061] For a payload consisting of voice-coding data, the format of thepayload of an RTP packet complies with the diagram of FIG. 7. The usefuldata of the RTP packet correspond to the following fields:

[0062] an NF (“Number of Frames”) field, coded on two bits, whichcontains a value on the basis of which is determined the number ofspeech frames that are contained in the RTP packet;

[0063] a C (“Encrypted”) bit, which is set to the logic value 1 wheninformation relating to encryption (comprising an algorithm identifierand a key identifier, see later) are contained in the RTP packet;

[0064] a P (“Protected”) bit, which indicates that the frames areprotected;

[0065] an E (“Emergency”) bit, which, when it is set to the logic value1, makes it possible to ensure specific processing at the level of theend equipment which receives the RTP packet;

[0066] a PRIO (“Priority”) field, the length of which is equal to threebits, which indicates a priority level associated with the speech framescontained in the RTP packet;

[0067] a source address, coded on 24 bits, which identifies the sourceaddress of the user (that is here the mobile station) which sends thespeech frames contained in the RTP packet, it being observed that theCSRC contributing source code identifies the end equipment (that is herethe base station) that generates the RTP packet and not this user;

[0068] a field containing, as the case may be, the speech framescontained in the RTP packet (“codec Frames”). The number of such framesdepends on the value of the NF field (see above). The length of thisfield is equal to 88 bits (11 bytes). Each frame is aligned with paddingbits set to the logic value 0, if necessary. Furthermore, the completefield is aligned with padding bits, if necessary. In one example whenthe speech frames are coded on 11 bytes, the total length of the fieldis equal to 0 bytes if NF=0, to 12 bytes if NF=1 (with one paddingbyte), to 24 bytes if NF=2 (with two padding bytes), or to 36 bytes ifNF=3 (with three padding bytes);

[0069] as the case may be, an algorithm identifier (“Algorithm ID”),coded on eight bits, which identifies the encryption algorithmimplemented for the data encryption; and,

[0070] as the case may be, an encryption key identifier (“Key ID”),coded on 24 bits, which contains the value of an encryption key used bythe encryption algorithm.

[0071] It will be noted that the algorithm identifier and the keyidentifier are contained in the RTP packet only if the bit C has thelogic value 1. Additionally, fields other than those described above maybe contained in the RTP packet. These fields contributing nothing to theunderstanding of the invention, they are neither represented in FIG. 7,nor made explicit in the present description.

[0072] As will have been understood, RTP packets may be transmitted withno payload, when the value contained in the NF field is 0 (NF=0). Onethen speaks of “empty” packets since they contain no speech frame.

[0073] The method according to the invention will now be described withreference to the flowcharts of FIGS. 8 and 9, in the case of a groupcommunication between three mobile stations.

[0074] It is recalled that according to the invention, the base stationsare at one and the same time equipments of the radio subsystem of theradiocommunications system (which undertake the radio interface with themobile stations), and end equipments of the transport network 300, whichsend and receive RTP packets.

[0075] Accordingly, let us consider the configuration represented inFIG. 1, where the mobile station 101 is under the coverage of the basestation 201, the mobile station 102 is under the coverage of the basestation 202 and the mobile station 103 under the coverage of the basestation 203.

[0076] Furthermore, let us assume that the mobile stations 101, 102 and103 are party to a group communication in half-duplex mode, set upaccording to the SIP session initialization protocol illustrated by thechart of FIG. 4.

[0077] More particularly, let us assume for example that the mobilestation 101 has the right to send for the alternation in progress and iscurrently sending. The speech frames sent by the mobile station 101 overthe radio channel are picked up by the base station 201. From there,they are transmitted to the MCU 400, through the IP network, in RTPpackets. The MCU transmits these RTP packets to the base stations 201,202 and 203. These RTP packets contain the CSRC code of the base station201, which is the source selected by the MCU to control the alternationin progress. The base stations 202 and 203 transmit them in their turn,by way of respective radio channels, to the mobile stations 102 and 103respectively.

[0078] The MCU 400, as central equipment, performs an arbitration incase of conflict between requests for the right to send originating fromvarious mobile stations by way of the corresponding base stations, andnotifies the various base stations of the result of this arbitration. Itmust also be able to warn without delay the mobile stations in receptionphase of the end of the alternation in progress, which corresponds tothe cessation of the sending of speech frames by the mobile station thathad obtained the right to send for the alternation in progress. In thisway, these mobile stations in reception phase have the possibility ofrequesting the tight to send.

[0079] To do this, the invention proposes that an indication element,included in the RTP packets, fulfil a certain number of functions inrespect of management of alternation.

[0080] In one example, the indication element may have as function, incombination with the CSRC code, to indicate to the base station selectedby the MCU that the right to send has been granted to it. In oneexample, the indication element actually has this function when it ispresent, with a first given value, in the RTP packets sent by the MCU tothe base stations 201, 202 and 203.

[0081] Moreover, according to the invention, the indication element alsohas as function, when it is present with a second given value, in theRTP frames transmitted to the MCU from the base station having the rightto send (i.e., that whose CSRC code is indicated in the RTP packetstransmitted by the MCU) to indicate to the MCU, on the one hand thatsaid base station acknowledges receipt of the right to send which hasbeen granted to it by the MCU, and on the other hand that it isrequesting maintenance of this right to send.

[0082] Moreover, the indication element furthermore has as function whenit is present, with a third given value, in an RTP packet transmitted bythe. MCU to the base stations, to indicate to the base stations thatthey may request the right to send. The one among them that will beselected by the MCU will then take control of the next alternation.

[0083] Preferably, the indication element finally has as function, whenit is present with a fourth given value in an empty RTP packet which istransmitted to the MCU from the base station having the right to send,to indicate to the MCU that said base station relinquishes its right tosend. This occurs when the alternation in progress has terminated, thatis when the mobile station which had obtained the right to send for thealternation in progress, ceases sending speech frames.

[0084] These functions of the indication element will be more clearlyapparent on reading an exemplary embodiment of the invention whichfollows. In one example, the first and the second given values of theindication element are identical. Likewise, the third and the fourthgiven values of the indication element are identical, and different fromthe first and second values.

[0085] Specifically, the indication element may be a field of anylength, which codes the aforesaid given values. In a preferredembodiment, this indication element may advantageously be reduced to abit, since it possesses two distinct functions when it is present in anRTP packet transmitted to the base stations from the MCU (as a functionof its value out of said first and said third different given values),and two distinct functions when it is present in an RTP packettransmitted from a base station to the MCU (here again as a function ofits value out of said second and said third different given values).

[0086] In a preferred embodiment, it is proposed to use for this purposethe M bit of the header of the RTP packets in conjunction with thefundamental mechanisms of operation of the MCU as RTP mixing entity.Said first value and said second value of the indication element arethen, for example, the logic value 1, while said third and said fourthgiven values are the logic value 0.

[0087] The flowchart of FIG. 8 illustrates the manner of operation of abase station as end equipment according to the invention. The example ofthe base station 201 is considered more particularly.

[0088] Let us assume that, in a step 301, the mobile station 101manifests its intention to transmit by an appropriate signaling to thebase station 201. In practice, this occurs when the user of the mobilestation 101 presses the PTT button (standing for “Push-To-Talk”) andspeaks into the microphone of the mobile station.

[0089] If the base station 201 is already receiving from the MCU,through the IP network, RTP packets with M=1 (thereby signifying thatthe right to send has already been granted by the MCU to another basestation which is sending RTP packets which are those retransmitted bythe MCU with M=1), and if the priority associated with the alternationin progress is not lower than the priority associated with the requestfrom the mobile station 201, then, in a step 302, it deduces therefromthat the right to send should be denied to the mobile station 101.Stated otherwise, the base station 201 decides that the mobile station101 cannot take control of the alternation. In a step 303, the basestation 201 then notifies the mobile station 101 that it has been deniedthe right to send. In practice, this is indicated to the user by theturning off of an indicator light of the mobile station 101 which hadbeen lit in step 301. The base station 201 continues to send over theair interface the speech frames received in the packets received fromthe MCU and the mobile station 101 remains in reception phase. It willbe noted that the priority associated to the request from the mobilestation 101, can be transmitted by the aforesaid signaling or becalculated by the base station 201 according to an ad-hoc scheme.Furthermore, the priority associated with the alternation in progress isindicated in the RTP packets received by the base station 201 (in theaforesaid PRIO field).

[0090] If, this is not the case, either because the base station 201 isnot receiving any RTP packet from the MCU, or because the priorityassociated with the request from the mobile station 101 is higher thanthat associated with the alternation in progress, then, in step 302, thebase station 201 deduces therefrom that it can grant (at leastprovisionally) the right to send to the mobile station 101 which hascommenced sending speech frames. The base station 201 thereforecommences, in a step 304, sending RTP packets containing these speechframes, with an M bit equal to the logic value 0 (M=Q). This value hasas function to indicate to the MCU that the base station 201 isrequesting the right to send.

[0091] Thereupon the base station 201 commences receiving (or continuesto receive) RTP packets with M=1. As indicated above, these packetscontain an SSRC synchronization source identifier, which corresponds tothe identifier of the MCU and a CSRC contributing source identifier,which corresponds to the identifier of the base station which has theright to send for the alternation in progress.

[0092] If the CSRC identifier is different from the identifier of thebase station 201, the latter deduces therefrom, in a step 305, that ithas not been selected by the MCU, that is that the right to send has'not been granted to it by the MCU, or, stated otherwise, that control ofthe alternation has been granted by the MCU to another base station. Inthis case, in a step 306, it interrupts the sending of RTP packets tothe MCU and notifies the base station 101 that it does not have theright to send. Step 306 is equivalent to the aforesaid step 303.

[0093] If, conversely the CSRC identifier of the RTP packets transmittedby the MCU is that of the base station 201, the latter deducestherefrom, in step 305, that it can continue the sending to the MCU ofthe RTP packets containing the speech frames sent by the mobile station101 over the radio channel. However, in a step 307, it henceforth sendsthese RTP packets with the M bit set to the logic value 1 (M=1), in sucha way as to indicate to the MCU that it acknowledges receipt of theright to send that has been granted to it by the MCU, and to indicatethat it is requesting maintenance of this right to send.

[0094] At any moment, the mobile station 101 can cease sending speechframes over the radio channel linking it to the base station 201, if theuser releases the PTT button. This event is monitored by the basestation 201 in a step 308. If the mobile station 101 continues to sendspeech frames, RTP packets containing these frames are generated by thebase station 201 and sent to the MCU. The method continues by repeatingthe aforesaid step 305. If, conversely, the mobile station ceasessending speech frames, then, in a step 309, the base station sends, tothe MCU, last RTP packets with the M bit set to the logic value 0. Theselast packets contain the last speech frames sent by the mobile station101 (and retarded by passing through a buffer memory of the basestation). The M bit with the logic value 0 then has as function toindicate to the MCU that the base station 201 is relinquishing its rightto send. In this way, the MCU is informed of the next cessation of thesending of RTP packets by the base station 201 even before these lastpackets are sent. The MCU, as will become apparent later in regard toFIG. 9, can then alert the other base stations by transmitting theselast RTP packets with the M bit set to the logic value 0 to indicatethat the end of the alternation in progress is near, and that it willsoon be able to request (and, for one of them, obtain) the right tosend.

[0095] Finally, when the base station 201 has sent the last speechframes in RTP packets with the M bit set to 0 (step 309), it sends, in astep 310, a certain number (for example three) of empty RTP packets,that is ones with no payload, and whose M bit is at the logic value 0.It sends several such packets so as to minimize the risks of nonreceiptby the MCU, which may occur if the network loses packets because of theoverloading of the routers. It is recalled that empty packets arecharacterized by an NF field containing the value 0. These empty packetshave as function to actually signal the end of the alternation inprogress. They make it possible for the MCU not to confuse the end ofthe alternation in progress with a request for the right to send thatoriginated from another mobile station situated under the coverage ofthe same base station 201 as the mobile station 101 which controls thealternation in progress. Indeed, such a request would also have the formof RTP packets containing speech frames (those sent by this other mobilestation and received by the base station 201 via another radio channel),whose M bit would also have the logic value 0, and whose CSRC fieldwould contain the same source identifier (that of the base station 201,which would be the same source seen by the MCU).

[0096] The flowchart of FIG. 9 illustrates the manner of operation ofthe MCU as central equipment according to the invention.

[0097] The MCU is initially in a standby state 700, wherein it receivesno RTP packet (it is assumed that all the participants in the groupconversation are silent). It is recalled that, when a base stationrequests the right to send, it sends RTP packets to the MCU, thesepackets containing speech frames (nonempty packets) with the M bit atthe logic value 0 (M=0).

[0098] Let us assume that at least one and perhaps several base stations(also called sources) send non-empty RTP packets such as these withM=0). When, in a step 701, the MCU receives these packets it selects, ina step 702, one of the base stations according to an ad-hoc selectionalgorithm. When a single source is sending RTP packets, this algorithmselects this source. When several sources are sending RTP packetssimultaneously, the selection algorithm may bring in, for example, thepriority, the identity of the sender or any other criterion.

[0099] Once the selection has been made, the MCU, in a step 703,transmits to all the base stations participating in the groupcommunication (namely, in the example, the base stations 201, 202 and203) the RTP packets received from the selected base station (namely, inthe example, base station 201), after having set the M bit to the logicvalue 1 and having placed its own identifier in the SSRC field and thatof the selected source in the CSRC field (the value of the CC field ofthe RTP packet is then equal to 1).

[0100] When, in a the step 711, the MCU then receives a new RTP packet,the MCU firstly verifies, in a step 704, that this packet does indeedoriginate from the selected source. For this purpose the CSRC identifierof the packet is used.

[0101] If this is the case, then the MCU verifies, in a step 705,whether the base station is requesting maintenance of its right to send.This is the case if the RTP packet has an M bit with the logic value 1.If so, this packet is transmitted as indicated above (return to step 703above). If on the other hand the M bit has the logic value 0, then, in astep 706, the MCU verifies whether it is dealing with an empty packet.If the packet is empty (that is if it contains no speech frame), this isbecause the source indicates the end of the alternation. Then, in a step707, the last RTP packets (those which remain in the buffer memory ofthe MCU) are transmitted as indicated above. (with reference to step 703above) but with the M bit set to the logic value 0, so as to indicatethe end of the alternation to the base stations. The MCU thereafterreturns to its standby state 700. If on the other hand the packet is notempty (that is it contains at least one speech frame), the RTP packet issent with the M bit in the logic state 1 (we return to step 703).

[0102] If, contrary to the assumption made above in respect of the testof step 704, the RTP packet received in step 711 does not originate fromthe selected source, two cases may arise. They are examined in a step708. If the priority of the source of the RTP packet received is higherthan that of the source selected, then, in a step 709, the source of theRTP packet received is selected as new selected source. The RTP packetreceived is then transmitted, by going back to step 703 with, in theCSRC field, the identifier of the new selected source. In the conversecase, the packet is rejected outright, in a step 710, and the MCU waitsfor the receipt of a new packet (return to step 711).

[0103] Referring to FIG. 8, it may be seen that when, in step 709, theMCU selects a new source although a source is already currently sendingRTP packets, the test of step 305 is satisfied for this last source, sothat it ceases sending to RTP packets over the IP network and causes thesending of speech frames by the mobile station concerned to cease.

[0104] It may also be seen that as soon as a base station receives RTPpackets with the M bit at the logic value 0 (indicating the next end ofthe alternation in progress) it is ready to accept a send request from amobile station since the test of step 302 will not be satisfied, sothat, in step 304, the base station will send RTP packets with the M bitset to the logic value 0.

[0105] The technique presented hereinabove therefore makes it possibleboth to undertake arbitration of requests for alternation by the basestations, preemption of the communication when the right to send isrequested by a base station with a higher priority, and anticipation ofthe end of the alternation in progress, so as to prepare the followingalternation as soon as the end of the alternation in progress isannounced by the sending by the selected base station of empty RTPpackets with the M bit set to the logic value 0.

[0106] A variant of the technique presented hereinabove makes itpossible to speed up the detection of the end of the alternation inprogress without risk of false detection in case of loss of RTP packets.The test of step 706 which reads “Packet empty with M=0?”, may bereplaced with the following test: “(Packet empty with M=0) or (packetwith M=0, the previous three packets not having all been lost)?”. Thus,the MCU detects the end of the alternation in progress upon receipt ofthe first packet with the M bit set to the logic value 0 and the MCUcannot confuse a start of alternation with the end of the alternation inprogress since, if the three empty packets with M=0 sent by the basestation at the end of alternation have been lost, a nonempty packet withM=0 will not be regarded as indicating the end of the alternation inprogress. The terms “previous” and “first” employed hereinabove refer ofcourse to the order of the RTP packets as indicated by the sequencenumber contained in the header of the RTP packets (see FIG. 6).

[0107] As will not have escaped the person skilled in the art, themanner of operation described by the flowcharts of FIGS. 8 and 9 mayrequire guard retardations in order for the equipments of the IPnetwork, namely the end equipments (base stations) and the centralequipment (MCU), to be protected against dropouts of links, whether thelatter have a physical origin or stem from a failure or from an overloadof the routers.

[0108] The technique presented hereinabove may effortlessly be extendedto more complex multimedia conferencing topologies than that presentedhereinabove by way of example, and in particular to a topology such asrepresented in FIG. 10. In this topology, an MCU 801 (or master MCU)undertakes the attaching and arbitration of the alternations betweensub-conferences managed by the MCUs 802 and 803 (or slave MCUs), thelatter actually performing the arbitration of the alternation and theattaching of the base stations 804 to 806, and 807 to 809 respectively.The person skilled in the art will realize that the operationalflowcharts for the base stations and for the master MCU are identical tothose presented previously with regard to FIGS. 8 and 9 respectively,while the manner of operation of the slave MCUs 802 or 803 complies withthe flowchart of FIG. 8 as regards their link with the master MCU 801,and with that of FIG. 9 as regards its links with the base stations804-806 or 807-809 respectively.

[0109] Thus, to give a simple example, at the start of an alternationthe slave MCU 802 sends the RTP packets received from a base stationsuch as 804 with the M bit at the logic value 0, leaving the M bit atthe logic value 0 for the RTP packets transmitted to the master MCU,while the M bit is set to the logic value 1 for the RTP packetsretransmitted to the various base stations 804 to 806 participating inthe communication.

[0110] The invention has been described hereinabove in a preferred butnonlimiting embodiment. The person skilled in the art will appreciatethat variant embodiments may be envisaged without departing from theprinciple of the invention.

[0111] In particular, the respective logic values of the marking bit Mthat are allotted to the various functions of this bit according to theinvention, may naturally be inverted. Moreover, and in particular in thecase where further functions have to be allotted to this indicationelement, it is possible to replace the marking bit M by a word ofseveral bits, or to associate it with one or more other bits in such away that the indication element may have more than two distinct values.

1. A method for managing two-way alternate communication in half-duplexmode between at least two end equipments (201-203) of a packet switchingtransport network in non connected mode (300), wherein an indicationelement (M) has as function, when it is present with a first given valuein packets transmitted from one (201) of said end equipments (201-203)to a central equipment (400) undertaking the management of thecommunication, to indicate to said central equipment (400), on the onehand, that said end equipment (201) acknowledges receipt of the right tosend that is granted to it by said central equipment (400) and, on theother hand, that it is requesting the maintaining of this right to send.2. The method as claimed in claim 1, wherein said indication element (M)has further as function, when it is present with a second given value inpackets transmitted by said central equipment (400) to said endequipments (201-203), to indicate to said end equipments that thealternation in progress has terminated.
 3. The method as claimed inclaim 1 or claim 2, wherein said indication element (M) has further asfunction, when it is present with the second given value in at least oneempty packet transmitted to said central equipment (400) from an endequipment (201) having the right to send, to indicate to said centralequipment (400) that the alternation in progress has terminated.
 4. Themethod as claimed in claim 1 or claim 2, wherein said indication elementhas further as function, when it is present with the second given valuein at least one packet transmitted to said central equipment from an endequipment having the right to send, to indicate to said centralequipment (400), when a given number of previous packets have not allbeen lost by the network (300), that the alternation in progress hasterminated.
 5. The method as claimed in any one of claims 1 to 4,wherein said central equipment (400) retransmits, to said end equipments(201-203), the packets received from said end equipment (201) having theright to send and containing the indication element (M) with said firstgiven value as long as it maintains the right to send granted to saidend equipment.
 6. The method as claimed in one of the preceding claims,wherein the packet switching transport network in non connected mode(300) is an IP (Internet Protocol) network.
 7. The method as claimed inclaim 6, wherein the packets transmitted over the network (300) are RTP(Real time Transport Protocol) packets, the communication being set upas an RTP/RTCP (Real time Transport Control Protocol) session.
 8. Themethod as claimed in claim 7, wherein the indication element is themarking bit (M) of the header of the RTP packets, said first value ofthe indication element being the logic value 1 or 0, and said secondvalue of the indication element being the logic value 0 or 1,respectively.
 9. The method as claimed in claim 7 or claim-8, whereinthe RTP/RTCP session is initiated according to the sessioninitialization protocol SIP.
 10. The application of the method asclaimed in any one of claims 1 to 9 to a radiocommunications system forthe management of the push-to-talk function for individualcommunications or group communications between mobile stations(101-103), wherein at least certain of said end equipments (201-203) ofthe packet switching transport network in non connected mode (300) arebase stations of said radiocommunications system.
 11. Aradiocommunications system, in particular a private system forprofessional radiocommunications, comprising base stations (201-203) anda network equipment (400) that are linked by a packet switchingtransport network in non connected mode (300), wherein said basestations comprise means for the implementation of the method as claimedin any one of claims 1 to 9 as network end equipment and wherein saidnetwork equipment comprises means for the implementation of the methodas claimed in any one of claims 1 to 9 as central equipment.
 12. Thesystem as claimed in claim 11, wherein said network equipment (400) is amultimedia video conferencing equipment.
 13. The system as claimed inclaim 11 or claim 12, wherein said packet switching transport network innon connected mode (300) is an IP (Internet Protocol) network.
 14. Abase station intended for use as end equipment in the system as claimedin any-one of claims-11 to
 13. 15. A multimedia video conferencingequipment intended to be used as central equipment in the system asclaimed in any one of claims 11 to 13.